Many IT organizations are suffering for aging technology and software engineer retirement.
Over the 50 past years, organizations created software that performs critical business tasks. However this software may put organizations at risk. Indeed software was written in “legacy” languages (i.e. out-of-date languages still in use, for example Cobol) for which software engineers massively retire and to which new engineers are not educated. Moreover the documentation of this software (design, business rules, application logic) is usually poor, often non-existent or was lost. Such a characteristic does not help to make business logic assets perennial nor allow new engineers to straightforwardly capitalize on existing software. Because of this, organizations are suffering from two main handicaps:                Programming knowledge is being lost. Maintenance costs constantly increase while agility (capability for change) stagnates.        Business knowledge is being lost. Making changes to software is more and more risky and business objectives may not be reached.        
As a consequence the technical debt of software (i.e. the cost for maintaining an application to a given quality level or to restore quality to a target level) goes against organization objectives (alignment with new regulation, business change, capability to execute, cost of ownership).
Moreover organizations cannot rely on software that performs critical business when facing these risks:                Loss of skill: available skills on legacy programming languages are either junior (with very limited knowledge of the legacy system) or experienced developers which are about to retire. Therefore technical skills are either vanishing or, in the best case, actually succinct.        Loss of knowledge: business applications execute major and critical processes. Those processes usually are at the core of organizations strategy and expected progresses. Legacy software design documentation is usually limited when not lost. As a consequence new programmers may not be able to get access to it nor retrieve business logic prior to performing change requests. This is error-prone and may cause deplorable business impact. This is a direct technical debt impact.        Gap between deployed applications and the code base stored in configuration management repositories: application life cycle management (compilation from source, automatic deployment) is usually not automated for legacy business applications. It is not unusual that code base is altered and new releases of applications are deployed without impacting the configuration management. As a consequence the system in use may differ from the code base that is saved in configuration management repositories. Any future change impacting the code base stored in repositories will erase unsaved changes (they exist only in production code base).        Technical debt and cost of ownership: legacy application design and implementation are under influence of the constraints of their aging programming language. Years and decades of maintenance and evolution make those applications costly to maintain and make evolve; at the same time, resources are becoming rare. Therefore the cost of ownership of those systems is high.        Regulation change: some industries must constantly adapt to new regulations (banking, energy . . . ). It is key for applications in constant change that business logic is preserved at design level (i.e., in a technology-neutral form) and that all technical artifacts are automatically derived from design models that aim at preserving the business logic assets.        
To solve these problems, it has been proposed to transform legacy software to more current platforms having wider acceptance, which is called “modernization”.
Modernization from legacy technology to new technology is often requiring significant manual intervention. Manual work is error-prone due to the size of large legacy software that cannot be fully managed by a human mind (complexity, volume of algorithms and information). Hundreds and even thousands of man-days are required to modernize average legacy software.
A first automated approach is line-by-line transformation where all tokens [statements and keywords of the language, variables] in one line of code are transformed into a new line of code that performs the same operation. This thoughtless transcription (“we do not know what it does but it does the same”) of software from old technologies to new ones simply moves the technical debt to the new code base.
More advanced approaches are based on logic extraction. Patterns are used to identify semantics so as to understand what does each section of code versus how it does it. Such an approach is presented in international application WO2005069125.
However, as of today, automated modernization solutions still suffer from unacceptable limitations:                Transforming software based on programming languages (Cobol, fourth-generation languages) prior to the object-oriented paradigm stumbles over the “structured programming” paradigm. Moving to object-orientation, Service-Oriented Architecture (SOA) principles requires appropriate modernization concepts, techniques and tools. Therefore existing approaches does not significantly remove technical debt.        Transformations applied for modernizing software are similar to decompiling and recompiling programming languages. Therefore it is highly complex or even impossible for users of modernization systems (methods, tools . . . ), to customize transformations. As a consequence it is very difficult to modernize all the legacy code because of ambiguities in legacy code semantics and numerous exceptions to design patterns.        Modernization systems mostly use a kind of internal pivot representation formalism to carry out transformations. Legacy code base is transformed through the use of parsers relying on this pivot formalism. However this pivot is seldom based on public standards. Therefore even if users of modernization systems may create tailored transformations to manage semantic ambiguities, it may be risky to invest in specific modernization products. Data and code volume, business criticality of applications, sustainable investment and so on thus impose open standardized products.        
There is consequently a need for a method enabling describing, managing and executing semantic transformations in order to retrieve the business logic from the legacy system in such way that (a) the retrieved logic is independent from the legacy technology, that (b) it can be automatically transformed into the new code base and new database which are fully compliant with the new architecture and are no longer suffering from the technical debt of the legacy system, and that (c) it is markedly faster than any known computer and/or human method.